| AFiles: Installieren (Teil2) | WGet | Effizientes Programmieren (Teil2) |

WGet - Surfen einmal anders

Teil 1

Es funktioniert einfach nicht, das Internet. Warum, soll hier nicht näher erläutert werden, aber die einzelnen Konzepte und Spezifikationen liegen ja offen, sodaß es bei Bedarf jeder für sich herausfinden kann.

Nun ist es leider doch so, daß man dort hin und wieder brauchbare Sachen findet, die man gerne hätte. Meist hat man die Wahl zwischen schwerfälligen, ständig abstürzenden, wanzenverseuchten Elefanten (Voyager, Netscape und Schlimmeres) oder kryptisch-minimalistischen Einzellern (Lynx und diverse FTP-Clients).

Die wünschenswerte Lösung des Problems, ein brauchbarer Browser und eine vernünftige Netzwerktechnologie, existiert der Ansicht vieler Leute nach nicht. Rein technisch wäre zwar nicht viel dahinter, aber vorher müsste man leider die alteingesessenen Strukturen loswerden. Und das ist in den letzten 20 Jahren eben nicht passiert.

Dieser Workshop beschreibt daher einen alternativen Weg mit Daten im Netz umzugehen. Dazu wird ein Tool namens Wget verwendet. Die Idee die dahintersteckt ist, daß Daten, die man auf der eigenen Platte hat, in der Regel weniger Ärger machen als solche in irgendwelchen Netzwerken. Auch zeigt die Erfahrung, daß Browser wesentlich stabiler laufen, wenn sie sich nicht um abstruse Protokolle, überlastete Proxys und vom Anwender falsch dimensionierte Caches kümmern müssen. (Die Probleme einer verantwortungslos kaputtgemüllten WBStartup bleiben natürlich.)

Voraussetzungen

Wget ist im Grunde ein WWW-Browser ohne Benutzeroberfläche. Das heißt, man kann es nur vom CLI aus benutzen. Womit sich nun wohl die Anzahl der Leser auf ein Drittel reduziert hat.

Zum verbliebenen Rest: Das ist durchaus der Sinn der Sache, weil die Zielgruppe von Wget nicht der dumpf vor sich hinklickende Netscape-Fan ist, sondern Leute, die wissen, was sie wollen.

Man sollte also schon ein paar mal Zeilen in der s:user-startup geändert haben, wenn man diesen Workshop nachvollziehen will.

Es bedarf natürlich einer funktionierende TCP/IP-Verbindung nach außen. Eine bereits existierende Netzwerkinstallation von Miami oder AmiTCP ist daher notwendig.

Des weiteren wird angenommen, daß der Anwender in der Lage ist, mit dem Internet halbwegs ressourcenschonend umzugehen. Mit anderen Worten: Bevor einer 20MB saugt, sollte er überlegen, ob er eigentlich nicht ohnehin nur an 2MB davon interessiert ist. Auch wenn es einer CLI-Optionen mehr bedarf, um diese zu filtern. Auch wenn es eine halbe Minute mehr Zeit benötigt, um dafür kurz diesen Workshop oder die originale Dokumentation zu überfliegen.

Und nicht zuletzt empfiehlt es sich, irgendein Programm zu besitzen, das HTML-Seiten anzeigen kann. Da die Daten bereits auf der eigenen Platte sind, braucht man nicht unbedingt einen der "großen" kommerziellen Browser. In viele Fällen kann ein kleiner Offline-Browser wie z.B. MoreHTML vollkommen ausreichen.

Wget ist kein reines Amiga-Tool, sondern kommt aus der Unix-Welt. (Peng! Wieder ein paar Leser weniger.)

Mit anderen Worten: Wget ist von Haus aus so konzipiert, daß es vollkommen unbedienbar ist. Daher wird hier an den entsprechenden Stellen auf die diversen, aus vernünftiger Sicht unmotivierten (um nicht zu sagen: kranken) Besonderheiten in der Benutzung eingegangen. Unix-Kenntnisse werden daher nicht vorausgesetzt.

Besorgung und Rechtliches

Weil das Programm unter der berühmt-berüchtigten GNU License vertrieben ist, kann man wie bei allen solchen Tools den Quellcode von ftp://prep.ai.mit.edu/pub herunterladen.

Für Amiga gibt es Gott sei Dank auch eine fertig compilierte Version, die man sofort benutzen kann. Wie bei den meisten GNU-Programmen kann man es sich von dem FTP-Server der Geek Gadgets besorgen: ftp://ftp.ninemoons.com/pub/geekgadgets/current/amiga-bin/ Man suche jeweils nach einem Archiv, dessen Name mit wget beginnt.

Dort gibt es auch die benötigte ixemul.library. Sinnloserweise sind für diese Bibliothek derzeit die Versionen für alle Prozessoren in einem Archiv zusammengefaßt, sodaß man sich 2MB herunterladen darf, um dann ein paar Kilobyte davon zu verwenden.

Für den Anwender bedeutet die GNU License, daß ein Programm frei kopierbar ist, und im Falle von Wget auch, daß man es gratis benutzen kann. Details dazu in der Dokumentation des Programms.

Installation

Nun ist es lästig, den ganzen Krempel zusammenzusuchen. Des weiteren scheint sich momentan niemand um die Geek Gadgets Version von Wget zu kümmern, da dort derzeit nur die veralterte Version 1.4.2 liegt. (Alte Programmiererweisheit: Die Portierung ist meistens einfacher als die Wartung.)

Daher gibt es gemeinsam mit dieser Ausgabe ein LHA-Archiv, in dem sich die aktuellen Versionen von Wget (1.4.5) und ixemul.library (47.2) befinden, jeweils für 68000 compiliert.

Wer bereits ein existierende Installation der 'Geek Gadgets' hat, sollte wissen, wohin mit den Dateien in diesem Archiv.

Für die anderen (=meisten) folgt hier ein alternativer Vorschlag, an dem man sich nicht zu halten braucht, wenn man weiß, was man tut. Wer Wget mit diesen Hinweisen nicht zum Laufen kriegt, sollte es ohnehin besser nicht benutzen, weil er damit einigen Schaden anrichten kann.

Quelldatei	Zielverzeichnis
`wget/c/wget`	`c:`
`wget/help/wget.guide`	`help:`
`wget/libs/ixemul.library`	`libs:`
`wget/libs/ixnet.library`	`libs:`
`wget/env/TZ`	`envarc:` und `env:`

Der Wert der Umgebungsvariable TZ stimmt für Österreich, wer in einer anderen Zeitzone wohnt, muß ihn eben entsprechend ändern.

Die originale Dokumentation zu Wget befindet sich in wget.guide. Dieser Workshop kann und will sie nicht ersetzen, und man sollte sie sich einmal zu Gemüte führen.

Die Datei wget/usr/etc/.wgetrc verdient eine kleine Sonderbehandlung. Dabei handelt es sich um die Konfiguration von Wget. Beim Start wird nämlich nach einer Datei namens usr:etc/.wgetrc gesucht. Wird keine gefunden, schadet das nicht viel, da dann eben Standardwerte verwendet werden.

Jedoch wird ein Requester nach einem Assign oder Device namens usr: fragen, was lästig ist. Daher empfiehlt es sich, z.B. ein Verzeichnis namens work:usr anzulegen, und in den s:user-startup ein

assign usr: work:usr

zu machen. Zu Guter letzt kann man dann noch .wgetrc nach work:usr/etc/.wgetrc kopieren. Was .wgetrc genau macht, wird im nächsten Teil erläutert, einstweilen sollten die dort eingestellten Werte funktionieren.

Die restlichen, hier nicht angeführten Textdateien sollte man sich kurz durchlesen, damit man im Bilde ist.

Wer über das alles mehr wissen will, kann sich einmal auf der Homepage der Geek Gadgets umsehen.

Jetzt aber endlich zur Benutzung der Programms.

CLI-Optionen im Allgemeinen

Jene, die über die Eigenheiten von CLI-Optionen unter Unix bereits Bescheid wissen, können diese Absätze überspringen.

Im Unterschied zu AmigaOS wird unter Unix bei fast allem bei der Groß/Kleinschreibung unterschieden - "case sensitivity" heißt das im Fachenglisch. Heutzutage weiß praktisch jeder, daß dies ziemlich unsinnig ist, was die Benutzbarkeit eines Systems angeht. Unixler werden jetzt aufjaulen, aber die haben auch nie etwas von "Usability" gehört oder gar etwas darüber gelesen.

Im Klartext heißt das: Wenn man ein

wget --help

macht kriegt man eine kurze Auflistung der wichtigsten Optionen, bei einem

wget --HELP

nur eine Fehlermeldung bezüglich "unrecognized option".

Wer sich nun fragt, warum man zwei Minus Zeichen (-) vor dem "help" braucht, dem sei gesagt: Derlei abartige Sachen wie in AmigaOS, wo es eine Systemfunktion namens ReadArgs() zum Lesen von CLI-Argumenten gibt, spielt es unter Unix nicht. Dort werden solche Sachen entweder immer neu "mit der Hand" gemacht, oder mittels wenig hilfreicher und konzeptionell verwurschtelten statischen Bibliotheken wie getopts.c.

Für einen Programmierer ist es dann einfacher, wenn er alles, was mit "-" beginnt, als Option interpretieren kann, und den Rest als Dateinamen, oder im Falle von Wget als URI. Mit den meisten Unix-Programmen kann man einen Heidenspaß haben, wenn dann ein Dateiname mit "-" beginnt. Zum Glück tut eine URI das selten.

Die meisten Optionen haben ein Kurz- und ein Langform. Im Falle von --help z.B. lautet die kurze Variante -h. Man kriegt also auch auf folgende Weise die gleiche Übersicht wie zuvor:

wget -h

Wenn einer so etwas liest, weiß er natürlich nicht mehr, was gemeint ist. Darum wird während des Workshops immer die Langform verwendet. Tippfaule können die entsprechende Kurzform aus der Dokumentation erfahren.

Genauso wie unter AmigaOS gibt es auch bei Wget zwei Arten von Argumenten: solche, die nur für sich stehen, und solche, die einen weiteren Parameter erwarten. Nimmt man z.B. den AmigaOS-Befehl list, so wäre FILES ein Beispiel für erstere Gattung, und LFORMAT für zweitere.

In letzterem Falle kann (wie unter AmigaOS) der zweite Parameter durch eine Leerzeichen oder ein "=" getrennt sein. Ein --tries 20 ist also gleichbedeutend mit einem --tries=20. (Zur Bedeutung dieser Option siehe unten.)

FTP-Saugen

Zuerst einmal kann Wget das schlechte alte FTP. Es stellt sich die Frage: Warum sollte man zum FTP-en ein kryptisches CLI-Tool verwenden, wo es doch sowieso viele komfortable FTP-Programme für Amiga gibt. Das ist natürlich richtig, und zum herumschnüffeln in FTP-Verzeichnisen ist Wget auch denkbar ungeeignet. Praktisch ist es aber, wenn man ganz genau weiß, was man will.

Nehmen wir einmal an, man liest irgendwo, daß es ein nützliches Haushaltsprogramm gibt, das die Funktionalität einer Glühbirne hat. Und zwar kriegt man es von:
ftp://vienna.aminet.or.at/pub/aminet/game/gag/LichtTools.lha.

Das heißt, man weiß ganz genau, wo es sich befindet. Nun kann man sich natürlich dort einloggen, durch die Verzeichnisse klicken und dann die richtige LHA-Datei aus einer langen Liste auswählen.

Einfacher ist es aber, mit Hilfe des Clipboards im CLI einzugeben:

wget ftp://vienna.aminet.or.at/pub/aminet/game/gag/LichtTools.lha

In der Shell sollte sich dann etwa folgendes zeigen:

--19:54:50--
ftp://vienna.aminet.or.at:21/pub/aminet/game/gag/LichtTools.lha
           => `LichtTools.lha'
Connecting to vienna.aminet.or.at:21... connected!
Logging in as anonymous ... Logged in!
==> TYPE I ... done.  ==> CWD pub/aminet/game/gag ... done.
==> PORT ... done.    ==> RETR LichtTools.lha ... done.
Length: 10,699 (unauthoritative)

    0K -> ..........

19:54:53 (44.65 KB/s) - `LichtTools.lha' saved [10699]

Je nachdem, wie lange der Download dauert, hat man nach einiger Zeit im aktuellen Verzeichnis eine Datei namens LichtTools.lha.

Auf ein Neues

Nehmen wir einmal an, wir saugen gerade etwas Großes, z.B. das Basis Archiv für NetBSD mit beachtlichen 8MB Umfang:

wget ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga/ bin-dist/bin12D-199704/base.tar.gz

Nun hat man schon 5MB gesaugt, und plötzlich beschließt das Netzwerk einzugehen. Und die ganze halbe Stunde Warten war umsonst?

Nicht ganz. Zwei Wochen später funktioniert das Netzwerk wieder, und die alten 5MB liegen immer noch auf der Platte. Alles, was man jetzt zu tun braucht, ist einzugeben:

wget --continue-ftp ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga/ bin-dist/bin12D-199704/base.tar.gz

und Wget setzt dort fort, wo es vorher aufgehört hat - saugt also nur die fehlenden 3MB anstatt der vollen acht. Normalerweise zumindest, denn leider gibt es ein paar alte FTP-Server, die dieses Feature nicht unterstützen, und da bleibt dann leider nichts anderes übrig, als wieder von vorne anzufangen.

Zu beachten ist dabei, daß das alte, halbfertige Archiv in dem Verzeichnis liegen muß, von dem aus Wget diesesmal gestartet wird. Soll heißen: Wenn man unmittelbar, bevor man Wget loshetzt, ein

list

macht, sollte man ein base.tar.gz sehen.

Eines der Features von Wget ist aber, daß obiger Fall relativ selten eintrit. Das liegt daran, daß Wget sich von Haus aus nicht besonders daran stört, wenn eine Verbindung zusammenbricht.

Zwar motzt es kurz ein bisserl herum, bricht aber nicht ab. Schlauerweise wartet es eine gewisse Zeit, und versucht dann eine neue Verbindung aufzubauen, die dort fortsetzt, wo zuvor etwas schiefgegangen ist. Das heißt, ein Netzwerkausfall im Minutenbereich tut nicht weh.

Das ist vor allem dann praktisch, wenn man eine große Datei über eine instabile Verbindung holen will. Weil 23 mal ein --continue-ftp bringt es dann irgendwie auch nicht wirklich.

Schwaffelsperre

Wie wir bereits bemerkt haben, ist Wget Weltmeister im Märchenerzählen während es sein Arbeit verrichtet. Ein Beispiel für die Ausgabe zum Downloaden einer einzigen Datei gab es ja bereits oben zu sehen.

Der dabei unterhaltsamste Teil sind die vielen kleine Punkterl, die mehr werden, wenn man große Archive saugt. Das ist, wie nicht anders zu erwarten, ein alter Unix-Brauch. Begründen tut er sich darin, daß in alten Zeiten die Netzwerke noch unbrauchbarer langsam waren als heute, und daher alle aufrechten Netzwerk-Utilities die meiste Zeit nichts besseres zu tun hatten als Punkterl zu malen.

Natürlich waren die Punkterl bald sehr beliebt, nicht zuletzt weil man lässig in ihrem Rhythmus mitklatschen konnte. Manche Programme verwendeten auch "#", welche oft - genügend Daten vorausgesetzt - psychedelisch verkastelte Bildschirme lieferten. Und wenn die Punkterl einmal stehenblieben, tat das meistens auch Herz der geschundenen Kreatur hinter der Tastatur - also eine Art Netzwerkpuls, die Punkterl.

Tolle Sache, aber wen interessiert das heute? Klar, die traditionsbewußten Unixler, aber unsereins ist das oft ziemlich egal. Daher möglicherweise lieber:

wget -nv ftp://vienna.aminet.or.at/pub/aminet/game/gag/LichtTools.lha

wobei -nv für non-verbose steht. Man beachte das hier nur ein Minus zu verwenden ist, weil es konsistenterweise für -nv keine (dokumentierte) Langform gibt. Dann sieht man nur noch:

20:01:52 URL: ftp://vienna.aminet.or.at:21/pub/aminet/game/gag/LichtTools.lha [10699] -> "LichtTools.lha" [1]

was für den Normalverbraucher ausreichend sein sollte. Wer trotzdem Mitklatschen will, soll im Hintergrund eine Aufzeichnung vom letzen Musikantenstadl laufen lassen. Wäre Karl Moik in den Siebzigerjahren schon so bekannt gewesen wie heute, er wäre wahrscheinlich ein integraler Bestandteil des Unix-Systems.

Für die ganz Hartgesottenen gibt es dann noch --quiet, das überhaupt alles unterdrückt. Dieser Option sollte man sich aber nur bedienen, wenn man ganz genau weiß, was man kriegen wird.

Im Falle von Fehlern oder anderen herausragenden Ereignissen bleibt Wget sinnvollerweise eine alte Plaudertasche, -nv und --quiet haben also nur eine Auswirkung, wenn alles in Ordnung ist.

Wie es weitergeht

Damit sollte klar sein, wie man einzelne Dateien mit Wget auf die eigene Platte kriegt. Und Dank der zahlreichen Features hat sich damit das Problem mit der Stabilität des Netzwerks gelöst.

Der nächste Teil beschäftigt sich mit dem Saugen ganzer Verzeichnisbäume. Das Hauptproblem darin besteht, nicht gleich das halbe WWW auf der Platte zu haben. Dazu gibt es eine Menge CLI-Optionen, um den Aktionsradius von Wget einzuschränken.

<>NIL: ...........

wget.lha - Das Archiv zum Workshop

ftp://prep.ai.mit.edu/pub - der FTP-Server der FSF, die Heimat von Wget

ftp://ftp.ninemoons.com/pub/geekgadgets/current/amiga-bin/ - der FTP-Server der Geek Gadgets

aminet:text/hyper/moreHTML.lha - ein Offline Browser

....